System and method for achieving interoperability between endpoints operating under different protocols

ABSTRACT

A teleconferencing system for achieving interoperability between a multiple endpoints including a first endpoint following SIP protocol, a second endpoint following H.323 protocol and a third endpoint following a proprietary protocol. The teleconferencing system incorporates a signaling gateway and a call control server. In the teleconferencing system, the signaling gateway and a call control server are configured to perform policy-based management of calls between the first endpoint, the second endpoint and the third endpoint.

CROSS-REFERENCE TO RELATED APPLICATION

This regular U.S. patent application claims the benefit of priorityunder 35 U.S.C. 119 of U.S. provisional patent application No.61/194,921 filed Oct. 1, 2008, the entire disclosure of which isincorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates in general to systems and methods forteleconferencing and, more specifically, for teleconferencing systemsand methods providing interoperability between teleconferencingendpoints that operate according to different signaling protocols.

2. Description of the Related Art

There exist many teleconferencing systems that have endpoints operatingin accordance with different signaling protocols, includingstandard-based protocols such as SIP and H.323, as well as variety ofproprietary signaling protocols. Such diversity of the teleconferencingstandards presents interoperability problem, wherein the systems cannotinteroperate with one another. Existing interoperability solutionsconcentrate on real-time conversion of the media stream from oneprotocol to another, which results in latency issues, which degradeteleconferencing system performance and user experience.

Therefore, there is a need for systems and methods that would enableinteroperability between teleconferencing systems operating underdifferent protocols without compromising overall system performance.

SUMMARY OF THE INVENTION

The inventive methodology is directed to methods and systems thatsubstantially obviate one or more of the above and other problemsassociated with conventional techniques for achieving interoperabilitybetween endpoints of teleconferencing system, which operate according todifferent protocols.

In one aspect of the present invention, there is provided ateleconferencing system for achieving interoperability between at leasttwo of a first endpoint following SIP protocol, a second endpointfollowing H.323 protocol and a third endpoint following a proprietaryprotocol, the teleconferencing system including a signaling-only gatewayand a call control server. The signaling-only gateway and a call controlserver are operable to perform policy-based management of calls betweenthe at least two of the first endpoint, the second endpoint and thethird endpoint, enabling a direct flow of media data between respectiveendpoints.

In another aspect of the present invention, there is provided a methodfor achieving interoperability between at least two of a first endpointfollowing SIP protocol, a second endpoint following H.323 protocol and athird endpoint following a proprietary protocol. The method is beingperformed by a teleconferencing system including a signaling-onlygateway and a call control server. The inventive method involvesperforming policy-based management of calls between the at least two ofthe first endpoint, the second endpoint and the third endpoint using thesignaling-only gateway and the call control server to enable a directflow of media data between respective endpoints.

In yet another aspect of the present invention, there is provided acomputer-readable medium embodying computer-executable instructions,which, when executed by one or more processors of a teleconferencingsystem incorporating a signaling-only gateway and a call control server,are operable to cause the one or more processors to perform a method forachieving interoperability between at least two of a first endpointfollowing SIP protocol, a second endpoint following H.323 protocol and athird endpoint following a proprietary protocol. The inventive methodinvolves performing policy-based management of calls between the atleast two of the first endpoint, the second endpoint and the thirdendpoint using the signaling-only gateway and the call control server toenable a direct flow of media data between respective endpoints.

Additional aspects related to the invention will be set forth in part inthe description which follows, and in part will be obvious from thedescription, or may be learned by practice of the invention. Aspects ofthe invention may be realized and attained by means of the elements andcombinations of various elements and aspects particularly pointed out inthe following detailed description and the appended claims.

It is to be understood that both the foregoing and the followingdescriptions are exemplary and explanatory only and are not intended tolimit the claimed invention or application thereof in any mannerwhatsoever.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification exemplify the embodiments of the presentinvention and, together with the description, serve to explain andillustrate principles of the inventive technique. Specifically:

FIG. 1 illustrates an embodiment of the inventive system architecture atthe interface level.

FIG. 2 illustrates transferring a call with an external H.323 endpointaccording to an embodiment of the inventive concept.

FIG. 3 illustrates operation of the inventive signaling-only gateway inconjunction with a Call Control Server.

FIG. 4 illustrates the INVITE processing for DID, and the relevantresponse codes.

FIG. 5 illustrates pre-routing of the call in accordance with anembodiment of the inventive concept.

FIG. 6 illustrates redirecting the inbound call from an external H.323endpoint to another instance of the SIP-H.323 gateway deployed elsewhereaccording to an embodiment of the invention.

FIG. 7 illustrates the procedure for transferring an H.323 endpoint (X)from one SIP endpoint (A) to another (B).

FIG. 8 illustrates SIP-side call redirection in accordance with anembodiment of the inventive concept.

FIG. 9 illustrates the end-to-end H.323 call redirection.

FIG. 10 illustrates an exemplary embodiment of a computer platform uponwhich the inventive system may be implemented.

DETAILED DESCRIPTION

In the following detailed description, reference will be made to theaccompanying drawing(s), in which identical functional elements aredesignated with like numerals. The aforementioned accompanying drawingsshow by way of illustration, and not by way of limitation, specificembodiments and implementations consistent with principles of thepresent invention. These implementations are described in sufficientdetail to enable those skilled in the art to practice the invention andit is to be understood that other implementations may be utilized andthat structural changes and/or substitutions of various elements may bemade without departing from the scope and spirit of present invention.The following detailed description is, therefore, not to be construed ina limited sense. Additionally, the various embodiments of the inventionas described may be implemented in the form of a software running on ageneral purpose computer, in the form of a specialized hardware, orcombination of software and hardware.

Aspects of the invention deal with teleconferencing architectureachieving interoperability between endpoints that follow differentsignaling protocols.

Interoperability Between SIP, H.323 & Proprietary Endpoints Using aSignaling-Only Gateway & Third-Party Call Control Server

Embodiments of the invention introduce native support for SIP, H.323 andproprietary signaling protocols in a network and call managementinfrastructure of a teleconferencing system. Specifically, the inventiveconcept provides several infrastructure components that allow forinteroperability between audio/video endpoints that follow differentprotocols for call setup and session management, including the followingtypes of audio/video endpoints:

1. A variety of third-party SIP audio/video endpoints,

2. and a variety of third-party H.323 audio/video endpoints,

3. as well as proprietary endpoints.

In an embodiment of the invention, this seamless interoperability isimplemented using an inventive SIP-H.323 Signaling-only Gateway) alsoreferred to herein as Signaling Gateway) and a commercially availablecall control server. The following discussion assumes familiarity withvideo telephony protocols, especially H.323 and SIP.

1. A Brief Overview of an Embodiment of Invention

Standards-based video endpoints use signaling protocols such as SIP orH.323 as part of their call setup process. The media itself is typicallysent over RTP/RTCP (106 in FIG. 1) in the form of compressed mediastreams, which use compression standards such as G.722, H.263, or H.264,among others. The target consumers for the SIP-H.323 Signaling-onlyGateway are providers of such video conferencing endpoints, orinfrastructure for services, or both.

An embodiment of the invention is a SIP-H.323 Signaling-only Gateway,which performs the necessary handling of the SIP and H.323 signalingprotocols and protocol translation between them, in either direction. Wegenerally refer to the SIP-to-H.323 call direction as “outbound” calls,while the reverse, viz. the H.323-to-SIP call direction is referred toas “inbound” calls. While the SIP-H.323 Signaling Gateway participatesin the establishment of calls, it does not directly deal with the RTPmedia streams exchanged in the context of the call. The media isstreamed directly between the peer endpoints. FIG. 1 illustrates anembodiment of the inventive system architecture 100 at the interfacelevel. The management API 107 is based on XML-RPC.

Interoperability with proprietary endpoints 101 and 102 is achieved bythe SIP infrastructure 103, which is also used for third-party callcontrol. The respective endpoints incorporate media components 112 and114 and signaling components 113 and 115. The usage of the proprietaryprotocol is limited between the SIP endpoint and the third-party callcontrol server, while the server uses SIP for signaling with theSignaling Gateway 104 component. In certain configurations, the SIPinfrastructure may also be a SIP registrar, commonly known as a SIPserver. A Gatekeeper 105 is typically deployed on the H.323 side.

As can be seen from the above FIG. 1, the SIP-H.323 Signaling-onlyGateway 104 implements a SIP User Agent (UA) 108, to allow the placementor forwarding of outbound calls; and to provide inbound callnotifications, thereby allowing their acceptance or refusal by the SIPinfrastructure; to handle SIP error conditions; and to handlecall/session termination.

Similarly, the SIP-H.323 Signaling-only Gateway implements an H.323stack to serve as an agent 111 for external H.323 endpoints. The Gateway104 performs the necessary protocol translation 109 and maintains theH.323 and SIP sessions in harmonized states. Additionally, it registerswith a Gatekeeper 105 as an H.323 Gateway, if configured to do so, inmanaged H.323 environments. In an embodiment, the addressing component110 performs address translation between protocols.

2. Exemplary Features

Some exemplary features of the inventive Gateway component are listedbelow:

-   -   Implement a H.323 Gateway, presenting a set of H.323 endpoints        on the H.323 network with or without a Gatekeeper, by        implementing client-side RAS, H.225.0 Call Signaling & H.245        Call Control procedures. An embodiment of the invention supports        H.323 versions 4 and greater (including version 5).    -   Act as a source and destination of SIP sessions by implementing        a SIP endpoint. An embodiment of the invention supports SIP        version 2.0, as specified in RFC 3261.    -   Not implement RTP or media coding, relying on the usage of        standard codecs in the media plane, as conveyed by the SIP and        H.323 endpoints in the session-level signaling.    -   Maintain the mapping and interoperability of H.323 and SIP calls        in the signaling plane.    -   Provide the necessary configuration, logging and monitoring        functionality.    -   Interoperability testing and support for currently shipping        versions of several third-party SIP and H.323 endpoints.

The telecom industry has been witness to a competition between multiplenetwork protocols, especially in the voice and video communicationsmarketplace. For any protocols not supported natively by endpoints andinfrastructure components (such as SIP, H.323, XMPP, SCCP or any otheremerging public or proprietary standards), it makes a lot of sense todeploy signaling-only gateways to be available as parts of a distributedinfrastructure.

Unlike call signaling, media coding transmission should deal with asmaller and slowly changing set of standards, namely, RTP/RTCP, G andH-series media codecs. Since most existing endpoints (voice and videophones) already use RTP and ITU-defined codecs for media compression andtransmission, the signaling-only gateway makes it possible for theseendpoints to participate in calls with other types of endpoints, whileexchanging media streams directly between the different endpoints. Forexample, a SIP endpoint and an H.323 endpoint could participate in acall with the signaling being routed through the gateway, while themedia flows directly between the endpoints. This provides the bestpossible media experience, while reducing latency and loss ofinformation due to transcoding.

In cases where this will not be possible, the media streams can berouted through transcoders, media relays, or firewall traversal tools,as needed to resolve protocol, codec and transport problems. Inseparation of the signaling problem and delegating it to thesignaling-only gateway, makes it possible to address the optimum mediaexperience, separately. The signaling-only gateways and media relaysalso take care of orthogonal issues such as authentication, encryption,compliance enforcement etc. Some features, notably anything to do withadministration of the system, scale better if they are centralized.Reliable accounting and reporting is another area where infrastructuresupport is useful. For all of these reasons, the architectural choicefor the addition of a signaling-only gateway in the infrastructureprovides clear performance or quality benefits.

3. SIP and H.323 Signaling for Audio/Video Calls

A. Supported Media Types

In an embodiment, an SIP-H.323 Signaling Gateway 104 enables directmedia connectivity between H.323 and SIP endpoints 102 and 101. Themedia itself is sent using RTP/RTCP 106 in the form of compressed G.722,H.263, or H.264 compressed streams. The endpoint codec compatibilitycheck is implemented by a proprietary, or standalone SIP endpoint and/orthe SIP User Agent in the SIP Server 103 on one side; and the externalH.323 endpoint on the other side. At the same time, a SIP-H.323 Gateway104 acts as a conduit to enable this functionality. It does so bypassing through the relevant information, after providing the necessarytranslation between H.245 media management procedures on one side; andSIP INVITE/re-INVITE transactions with appropriate SDP payloads on theother side. The SDP payload in the SIP messages carries all relevantmedia information communicated by the endpoint, such as the codecssupported by the endpoint, annexes supported by the codecs (or profilesdepending on the particular codec), media characteristics such assupported picture resolution, etc. Media renegotiation is also supportedin the same manner over the SIP and the H.323 signaling protocols, byusing re-INVITEs and logical channel manipulation, in respective order.

B. Call Control

Multiple instances (up to several hundred) of SIP and H.323 calls aresupported by a single instance of the SIP-H.323 Gateway. The callcontrol functionality enables SIP and H.323 endpoints to place calls toeach other, to accept, refuse and hangup calls, or to hold and resumeactive calls. Additionally, it enables transferring an established callto another endpoint.

In an embodiment, the gateway provides basic calling functionalitybetween SIP endpoints and H.323 endpoints in the following manner:

1. It forwards an incoming SIP call to an H.323 destination. An IPaddress, an alias or a combination of the two is supported forspecifying the destination address. The gateway places an outgoing H.323call to accomplish this. It should be noted that a combination of the IPaddress and alias will typically use a separator of “##’ preceding thenumeric E.164 alias string; and it will be passed to the third partyH.323 systems for possible usage, such as direct dialing.

2. Similarly, in an embodiment, the gateway forwards an incoming H.323call to a SIP destination, by placing an outgoing SIP call.

3. In either of the above cases, the gateway may translate between H.245call control procedures and SIP INVITE/re-INVITE transactions withappropriate SDP payloads. In an embodiment, the gateway supports thefast connect procedure, as well as the regular connect, if required bythe H.323 endpoint. Specifically, the H.245 logical channel manipulationis translated to SIP re-invites with updated SDP.

4. In an embodiment, H.245 bandwidth management is also translated toSIP, using appropriate SDP payload. For example, the gateway supportsrequests for *downspeeding* that are initiated by the H.323 endpoint.The Gateway is responsible for managing the differences between SIP andH.323 protocols for call control.

5. In an embodiment, H.245 mechanisms such as master-slave determinationand conference control for distributed multiparty conferences, that arenot directly addressed by SIP, the H.323 UA portion of the Gatewaysupports these, in a manner that is transparent to the SIP endpoint.

6. In an embodiment, the gateway allows either endpoint to terminate aconnected SIP/H.323 call.

7. In an embodiment, the gateway handles any relevant error conditionsincluding SIP or H.323 errors, timeouts, or unexpected call termination.Both, the SIP and H.323 peers are notified of such conditions, asappropriate.

8. In an embodiment, the gateway allows the handling of mediaincompatibility between SIP and H.323 endpoints. It may do so, forexample, by providing the necessary translation between H.245 mediamanagement procedures on one side; and SIP INVITE/re-INVITE transactionswith appropriate SDP payloads on the other. The actual determination ofmedia compatibility is performed directly at the endpoints, while thegateway translates and propagates these decisions across protocolboundaries.

9. In an embodiment, in the event where no compatible media is availablebetween the endpoints, the third-party call control server induces amedia relay and/or transcoder in the media path.

10. In an embodiment, the gateway allows SIP and H.323 endpoints tocontrol the session using SIP re-INVITEs and H.254 channel manipulation,respectively. It also supports other SIP message types including atleast INVITE, ACK, CANCEL, BYE, INFO, OPTIONS, REFER, REGISTER andSUBSCRIBE/NOTIFY. This allows for registration and atomic transferoperations.

In an embodiment, the Gateway may support Hold and Resume functionalityfor SIP and H.323 calls. In an embodiment, the gateway also allowstransferring an H.323 endpoint to a different SIP endpoint.

1. In an embodiment, the gateway allows an endpoint to hold or resume aconnected SIP-H.323 call.

2. On the H.323 side, the gateway may support the Phase D Call servicesdefined in H.323 V5 Section 8.4. In an embodiment, the gateway maysupport Hold/Resume initiated by the H.323 endpoint using the procedurelaid out in H.323 V5 section 8.4.6 for third party initiated pause. Inan embodiment, the gateway translates this into appropriate SIPtransactions. Specifically, the gateway sends a SIP re-INVITE withmodified SDP to reflect the held/active session description. It is notedthat H.450.4 also defines a supplementary mechanism for Call Hold. In anembodiment, the gateway supports H.450.4, as an optional service, whichdoes not necessarily cause a change in the session description (SDP).

3. On the SIP side, the gateway may support Hold/Resume initiated by theSIP endpoint using re-INVITE with held/active session descriptions. Inan embodiment, the gateway translates this into appropriate H.323transactions. It uses H.323 V5 section 8.4.6 for this purpose, and italso employs third party call control procedure to put the H.323 leg ofthe call on hold.

4. In an embodiment, the gateway allows accepting an incoming H.323 calland immediately putting in on Hold. In such situations, it refuses theattempts of the remote H.323 side to resume such call. Similarfunctionality is provided for incoming SIP calls. This is important tosupport standard SIP third-party call control procedures.

5. As shown in FIG. 2 (200), the SIP Call Management Server mayimplement 3pcc (third party call control) to enable a SIP endpoint 201in transferring a call with an external H.323 endpoint, to another SIPendpoint 202. In this scenario, the user agent 205 in the CallManagement Server 203 first disassociates the internal-facing andexternal-facing sides of a call that has been put on hold. It thenterminates the original SIP call; and it either places a new outgoingSIP call, or it accepts an incoming SIP call using user agent 206. Thegateway does support such 3pcc for call transfers. 6.

Besides 3pcc, the inventive Gateway may also support the SIP REFERrequest for call transfer.

C. In-Call DTMF Dialing

In an embodiment, the gateway supports in-call DTMF signaling. When insignaling-only mode, it uses SIP INFO messages with appropriatetext-based payload; which is translated from/to H.323 “User InputIndication” messages on the H.323 UA (user agent) module of the Gatewayon the H.323-facing end. The gateway also supports a separate RTP streamfor the DTMF messages. This employs SIP re-INVITEs with appropriate SDPpayload and corresponding H.245 logical channel manipulation.

D. In-Call Media Control

There are two widely used methods for requesting video imagerefreshment. The first method employs the extended RTP Profile forRTCP-based feedback and sending RTCP generic control packets, asdescribed in RFC 4585. The first method is outside the purview of theSIP-H.323 Gateway 104, because it is employed directly between theendpoints. On the other hand, the second method described herein belowdoes involve the SIP-H.323 Gateway. The second method uses applicationprotocol-specific commands, such as the H.245 FastUpdateRequest, whichis commonly used by H.323 endpoints to request intra-frames. In anembodiment, this may be supported using SIP INFO messages to translatethese requests as described.

This may be achieved by sending SIP INFO methods to the peer, with a SIPmessage body based on the XML Schema for Media Control as defined in theInternet Draft for XML Schema for Media Control(draft-levin-mmusic-xml-media-control-07). The SIP INFO message bodyappears as below:

... Content-Type: application/media_control+xml Content-Length: 177 ...<?xml version=“1.0” encoding=“utf-8” ?> <media_control> <vc_primitive><to_encoder> <picture_fast_update> </picture_fast_update> </to_encoder></vc_primitive> </media_control> ...

Ignoring the fast-update requests can result in extreme blockiness andthe user-experience would suffer. Specifically, the SIP-H.323 SignalingGateway translates the H.245 FastUpdateRequest method into a SIP INFOmessage that carries an intra-frame request, based on the XML Schema forMedia Control.

As discussed in the previous section, the gateway may supportdownspeeding in the midst of a call. It supports requests to reduce thebitrate, initiated by the H.323 endpoint; and it also makes suchrequests on behalf of the SIP endpoint. Specifically, we honor the H.323endpoint's requests to close/re-open LogicalChannels. More importantly,we also support the FlowControlCommand when used:

-   -   In conjunction with closing/re-opening LogicalChannels as        described in Phase D Call services defined in H.323 V5 Section        8.4. (Refer Section 8.4.1 on Bandwidth changes for        Downspeeding),    -   Or in conjunction with H.245 LogicalChannel Bitrate Change        messages, or any other H.245 control procedures (as defined in        H.245 V9).

Such requests are translated into SIP re-INVITES with modified SDP. Ineither case, the gateway processes the incoming request from theexternal H.323 endpoint and relay it to the AVNM using SIP. In anembodiment, it may be important that the logic for generating theresponse lie on the SIP side; and that the Gateway simply relays the SIPresponse onto the H.323 side. In an embodiment, the gateway alsosupports requests initiated by the SIP side, using SIP re-INVITES withmodified SDP, and it translates them using the H.323 proceduresdescribed above.

In an embodiment, the same mechanism may be used for the conversion ofaudio-video calls into audio-only calls, and other media-centric callcontrol use cases.

4. Packaging, Environment & Manageability

A. Implementation, Packaging and Environment

In an embodiment, the SIP-H.323 Gateway is supported on MicrosoftWindows and on several Linux platforms. The gateway supports SIP andH.323 for call control, as described earlier. In addition, the gatewaysupports a versioned management API for configuration, security andcontrol. This makes use of XML-RPC over port 80.

B. Support for Debugging and Testing

To facilitate verification and testing, the gateway may provide anoptional, simple command-line interface to:

-   -   Display the content of state change and event notifications,    -   Invoke the necessary actions, and    -   Query current state of API objects and structures.

In an embodiment, the gateway also provides the capability to log usagedata and calls.

C. Configuration, Monitoring and Management Support

In an embodiment, the Management API may be designed as a web service,using HTTP and XML, while following XML-RPC syntax. The managementinterface is kept separate from the call control portion of theSIP-H.323 Gateway. The purpose of this API is to allow configuration andmanagement, to view or edit the state for each connection to an H.323 orSIP endpoint, or infrastructure component.

Some examples of the managed/stateful objects include:

1. Any session involving the gateway, along with session-specific info.

2. The SIP-H.323 Gateway 104 version information.

3. A flag enabling or disabling the connection.

4. The type and friendly name of the network.

5. The maximum number of concurrent SIP and/or H.323 calls.

6. The local address, viz. IP address and port, for SIP.

7. H.323 gatekeeper 105 configuration:

a. Mode (not present, or statically configured),

b. Connection type (we can register as a gateway with a prefix, or as aneighbor gatekeeper or border element, as appropriate),

c. Network address (static, or dynamic)—When statically configured, theTCP port will be specified in the address, or the default of 1719 willbe used,

d. Connection state (not connected, discovering, connected, or rejected)and,

Without loss of generality, only one gatekeeper or border element perconnection will be configurable.

8. H.323 addressing information: Gateway alias or aliases.

In addition to the above, the usage of implementation-specific sharedresources (such as IP ports, etc.) on the host server may beconfigurable. For example, this may include the following:

1. IP Port for H.225.0 RAS (default=1719, range=1 to 65535).

2. IP Port for H.225.0-Q.931 (default=1720, range=1 to 65535).

3. IP Port Range for H.245 (default range=5555-5574, allowed=1 to65535).

4. IP Address & Port for SIP.

In an embodiment, the default address of the SIP server may besip:b2bua@127.0.0.1:5060.

In an embodiment, the default address of the gateway may besip:gateway@127.0.0.1:6060.

In an embodiment, the logging functionality is also configurable.

Third-party call control, routing and policy-based management of callsbetween heterogeneous SIP and H.323 endpoints.

Now, advanced features provided by various inventive components will bedescribed in detail, namely the third-party call control andpolicy-based management of calls between third-party SIP and H.323endpoints, and with proprietary endpoints. This can be further dividedinto the following:

1. Proximity-based routing of calls involving combinations ofproprietary and standards-based third-party endpoints. This may involverouting calls across IP networks using pre-configured IP ranges. In anembodiment, the routing component would ensure the selection of theoptimal gateway from a set of available infrastructure components. Itwould also ensure the redirection of endpoints to alternate gateways, ifdictated by routing policies.

2. Bandwidth management and usage accounting for calls involvingcombinations of proprietary and standards-based third-party endpoints.

3. Seamless setup and management of calls between proprietary andstandards-based third-party endpoints. Advanced call setup features suchas transfer, multiparty conferencing, and seamless conversion from/topoint calls to/from multiparty calls for standards-based third-partyendpoints. In an embodiment, these features may be implemented usingthird-party call control for combinations of proprietary andstandards-based endpoints, wherein the standards-based third-partyendpoints would not support these features on their own merit. In anembodiment, infrastructure components would determine capability of thethird-party endpoints, and apply third-party call control proceduresneeded to achieve the desired call setup operation.

1. Incoming SIP Call Support

In an embodiment, the inventive SIP-H.323 signaling-only gateway (alsoreferred to herein as inventive server) caters to requests coming from aSIP endpoint to initiate a session with an external H.323 endpoint. TheH.323 URL is supplied in the “To:” header of the SIP INVITE. Addressingoptions include the H.323 endpoint's IP address, host name, or an H.323alias string (with or without extensions). The “From:” URL is formattedto indicate caller information to the called H.323 endpoint.

In an embodiment, the gateway accepts the incoming SIP invite, performsthe necessary protocol translation and establishes the outgoing H.323session. It provides the SIP endpoint with a notification regarding theacceptance or refusal of the call by the external H.323 endpoint. Ithandles errors on the SIP and H.323 side, allows call termination and,it entertains requests to change the state of the call.

For ease of reference and consistency, one may refer to calls placedfrom SIP endpoints to H.323 endpoints as “outbound” calls.

2. Incoming H.323 Call Support

In an embodiment, the SIP-H.323 Signaling-only Gateway may cater torequests from an external H.323 endpoint to initiate a session with aSIP endpoint. For incoming calls, any address information available inthe H.323 call setup messages is retrieved and encoded in SIP “From:”and “To:” headers. In an embodiment, the SIP-H.323 gateway normalizesthe incoming address information, as needed for consumption by the SIPinfrastructure and endpoints. This is specified in greater detail, inthe following discussion. In case all the necessary addressinginformation isn't available at once during call setup, then the gatewayaccumulates and updates it over time.

With regards to addressing, the SIP-H.323 Signaling-only Gatewayincludes the callee's H.323 alias address, specifically, the*dialedDigits* in the user part of the SIP URL. For example, the SIP URLin the “To:” field of the SIP Invite from the SIP-H.323 gateway to theSIP infrastructure could be formatted as:

sip:<N>@<b2bua-address>;user=dialedDigits where, <N> is the extension ofthe SIP endpoint/callee, and <b2bua-address> is the address of the SIPinfrastructure piece.

It should be noted that the URL patterns are customizable, by using aXML-RPC based management API.

In an embodiment, the SIP-H.323 Signaling-only Gateway may accept theincoming H.323 call, performs the necessary protocol translation andestablishes the outgoing SIP session. The gateway may provide the SIPendpoint with a notification to allow the acceptance or refusal of thecall by the SIP endpoint. This notification includes the calling andcalled party addresses and a call identifier at the very least. Thegateway may handle errors on the SIP side and on the H.323 side, itallows call termination and, it entertains requests to change the stateof the call. In an embodiment, the SIP-H.323 Signaling-only Gateway maywork with an optional Gatekeeper as outlined in the followingdiscussion.

For ease of reference and consistency, one may refer to calls placedfrom H.323 endpoints to SIP endpoints as “inbound” calls.

3. Gatekeeper and Direct Inward Dialing (DID)

With reference to FIG. 3, embodiments of the SIP-H.323 Gateway 104 canregister with the configured Gatekeeper 105 as an H.323 Gateway, usingH.323 RAS, on behalf of all the SIP endpoints 101 that it serves. In anembodiment, the gateway's alias is a configurable prefix. In anembodiment, the dialedDigits alias is broken down into the gateway'sprefix and the SIP endpoint's extension. In an embodiment, the gateway'smanagement API supports static configuration for the Gatekeeper address;and automatic discovery is also possible. In an embodiment, theSIP-H.323 gateway also supports operation without a Gatekeeper 105.While operating with a Gatekeeper, the gateway augments the incomingcall notifications, including calling and called party addresses.Specifically, it reports the Q.931 called party number and H.225.0destination address, if available.

In an embodiment, the inventive SIP-H.323 gateway may do the following:

-   -   It performs the needed minimum validations on the addresses; and    -   It retrieves relevant parts of the destination address for user        lookup, in support of DID/DDI/call-through. This is illustrated        in FIG. 3.

The SIP B2BUA & Call Routing

The SIP infrastructure 302 employs a B2BUA entity 310 to host the SIPlistener and create a SIP call entity. This SIP call UAC or UAS entityis owned by each of the peer call handles 313 and 314; and ultimatelydispatch the SIP session to/from the SIP-H.323 gateway. The SIPsignaling protocol is used for call control and communication betweenthe B2BUA and the SIP endpoint 101 on one side; and the SIP-H.323Signaling Gateway 104, on the other side.

With reference to the FIG. 3, the SIP infrastructure is represented as aB2BUA entity 310, which has a scope that spans several SIP sessions intime; and is shared by several sessions at any given instance as well.This architecture allows for third-party call control. Further, the peercall handles 313 and 314 own their respective peer B2BUA SIP callobjects: UA Client 311 and UA Server 312. These SIP call objects arecomplementary in the context and scope of a SIP transaction, as definedin RFC 3261, well known to persons of skill in the art. Specifically, ifone acts as a SIP Server, then the peer acts as a SIP Client for thelife of that SIP transaction. Of course, the client/server roles canchange in the context of the parent SIP session/call.

In an embodiment, the SIP call object on the H.323-facing side talks tothe SIP-H.323 gateway. Likewise, the SIP call object on the SIP-facingside will talk to the SIP endpoint; or to another gateway, orinfrastructure component. In parallel, the call handle that owns theSIP-facing SIP call object may optionally use the third-party callcontrol server component 308 to employ another proprietary or standardprotocol to communicate with the SIP endpoint. The SIP infrastructuremay also integrate with a user database 309, for looking up the calleeand the corresponding SIP endpoint. This allows automatic routing of thecall to the SIP endpoint, aka DID.

In an embodiment, the SIP users' H.323 addresses for DID are advertisedby the user management infrastructure 315. This allows the assignment ofgateways to SIP B2BUA servers, assignment of prefixes to gateways, andextensions to SIP users. In this way, it is possible for every SIPendpoint to have its own unique H.323 address for direct dialing. If theH.323 address for the user has not been configured, it is be assignedautomatically and maintained by the SIP infrastructure to ensureuniqueness. The gateways prefixes and user extensions are propagatedacross the SIP infrastructure. With reference to FIG. 4 illustratingmethod 400, the “dialedDigits” from the “To:” header of the incoming SIPINVITE 401 will be the key for searching the user database 316. Thedialed digits are a concatenation of the gateway prefix and the SIPuser's extension. If no SIP user with a matching H.323 address is foundat 403, then the border SIP B2BUA server will route the call to thereceptionist for that network (417). If the user is found, then itsnetwork will serve as the destination video network for the routingmodule. If the receptionist is not found, the invite is rejected (418,423) and the SIP response is sent (419, 424).

In an embodiment, if the user lookup does not return a match, or if itreturns multiple matches, then the call will be routed to theReceptionist for the selected network (417, 420 and 421), or the defaultnetwork, as appropriate. If the callee is in “blocked calls” mode (404,406), or if they have reached their limit (404, 408) for the maximumnumber of active calls, then a message indicating that the user is notavailable is sent back to H.323 endpoint (411, 412, 415 and 416).

In an embodiment, if the user accepts the call or in auto answering mode(405), the invitation is accepted (409) and SIP response 410 is send.Finally, if the user ignores the call (407) invitation is rejected (413)and SIP response is sent (414).

In an embodiment, the SIP server uses specific response codes, whensending a response to the gateway. These are listed below, and they aretranslated by the gateway, into appropriate H.323 reason codes.

-   -   Provisional 1xx    -   Successful 2xx    -   Redirection 3xx    -   Request Failure 4xx    -   Server Failure 5xx    -   Global Failures 6xx

Specific and discrete request failure (4xx) or server failure (5xx) orglobal failure (6xx) codes will be used to convey user actions andendpoint/system events and states, as appropriate. FIG. 4 illustratesthe INVITE processing for DID, and the relevant response codes.

Network Management: Routing & Bandwidth Accounting

In an embodiment, a SIP-based network management infrastructure allowsthe dynamic creation of video ports on the video network for the SIP andH.323 endpoints. The video network represents a resource pool used forbandwidth accounting. The video ports represent an instance of anendpoint's access to this resource pool. The video networks are alsoconfigured to represent the IP network topology. With pre-routing foroutgoing calls; and with gateway-redirection for inbound calls, ourrouting functionality ensures optimum resource allocation. Bothpre-routing and gateway-redirection are explained hereinbelow.

An enterprise may have multiple connections to the internet, and toother networks. Bandwidth accounting benefits from the ability to routecalls to the appropriate “destination” video network (terminal node).Managed video networks and bandwidth management is one of the uniquefeatures allowed by our SIP infrastructure and the SIP-H.323Signaling-only Gateway.

As a use case and an example, consider the case where a SIP endpoint onthe “Northern California” managed video network calls a H.323 endpointon the “London” managed video network. Both the video networks aremanaged by an instance of our SIP infrastructure. Each instance, in turnis enabled with an instance of the SIP-H.323 signaling-only gateway. Ifwe are to choose the nearest network, or option #1 (521) for pre-routingas described in the decision tree in the following section, then we willend-up accounting the usage of bandwidth by the H.323 endpoint againstthe “Northern California” video network. Ideally, we would have liked itto use the “London” video network and account the bandwidth against aconfigurable trunk between the two networks.

The above discussion advocates the value in considering options forPre-Routing based on the callee's information (504) (and not thecaller's information). In an exemplary embodiment, then, the,infrastructure may preferably to behave as follows:

1. Implement Pre-Routing using the callee's information 504, which mapsonto options #3 512 and #4 506, as highlighted in decision tree, in thefollowing section. Pre-routing is based on IP Range configuration and IPaddress of the external H.323 endpoint.

2. The SIP infrastructure imposes online IP Address lookup functionalityon the SIP-H.323 gateway. In an embodiment, this is accomplished by theSIP-H.323 gateway and may be enabled using the SIP OPTIONS method.

3. In an embodiment, the SIP infrastructure allows IP address rangeconfiguration; and falls-back to option #1 for pre-routing, in the eventthat the destination video network cannot be resolved by the above.

4. In an embodiment, a call is rejected when the SIP-H.323 gatewaycapacity has been exceeded (in terms of the number of concurrent calls).In an embodiment, the call is not re-routed to another destination videonetwork so as to prevent resulting poor usage of bandwidth.

In an embodiment, for inbound calls, bandwidth accounting may depend onthe selection of the “source” video network (leading node) or theSIP-H.323 gateway used for the call. To summarize, the Pre-Routing foroutbound calls must be based on callee information, while SIP-H.323gateway selection for inbound calls must be based on caller information.In general, for accuracy in the bandwidth accounting and usage, thegateway selection 402 may be based on the proximity to the H.323endpoint, while allowing the SIP infrastructure to do the bandwidthmanagement on the SIP leg of the call. Gateway selection and redirectionis discussed further in a later section of this document.

6. Outbound Call Pre-Routing

The H.323 destination addresses provided by the SIP endpoint userincludes the H.323 callee's IP Address or the H.323 alias. In anembodiment, the SIP infrastructure maps this onto a video network aspart of the Pre-Routing process. FIG. 5 (steps 501-523) illustrates thePre-Routing decision tree 500.

In an embodiment, the determination of the destination video network orterminal node for routing is primarily the responsibility of the SIPinfrastructure. The SIP The SIP infrastructure is already aware of thenetwork topology on the SIP side and the SIP endpoints' IP addresses.The SIP infrastructure relies on the SIP-H.323 gateway to provide theH.323 endpoint's IP address. Based on the information provided by thegateway; and based on the configuration, the SIP infrastructure uses thecombination of callee's IP address and alias and/or caller's location orrealm information to perform Pre-Routing.

7. Endpoint IP Address Lookup

In an embodiment, the SIP infrastructure, B2BUA or third-party callcontrol server may request the SIP-H.323 gateway to resolve an H.323alias into the IP address for the H.323 endpoint. It will use the SIPOPTIONS method for this purpose. In an embodiment, the actual lookupwill be performed by the SIP-H.323 gateway; and the gateway will consultthe H.323 Gatekeeper, as appropriate.

In an embodiment, the SIP-H.323 gateway will always provide the externalH.323 endpoint's IP address for inbound calls to SIP endpoints. Thisinformation will be included as part of the addressing information inthe SIP INVITE from the SIP-H.323 gateway to the SIP infrastructure. TheSIP infrastructure will use this information for routing, optimumnetwork/resource pool allocation and for bandwidth usage accounting incalls. Based on the address of the H.323 endpoint, the SIPinfrastructure could redirect it to another SIP-H.323 gateway if that ismore suitable for purposes of optimum network/resource pool allocationand for bandwidth usage accounting.

8. Bandwidth Accounting for Inbound Calls

Attention is now directed to bandwidth accounting for inbound H.323 toSIP calls. We take the same use case employed earlier, wherein we have aSIP endpoint on the “Northern California” video network, which, thistime around, receives an incoming call from a H.323 endpoint near the“London” video network. At least one of the two video networks isenabled with a SIP-H.323 gateway. If the two networks are both enabledwith their own separate gateways; and if the SIP endpoint in northernCalifornia advertises its H.323 address to use the northern Californiangateway's prefix, then the northern Californian gateway may get used inthe call. And we could end-up accounting the usage of bandwidth againstthe “Northern California” video network.

In an embodiment, ideally we would have liked to use the “London” videonetwork and account the bandwidth against the trunk between the twonetworks. One way to make this happen is by changing the H.323 useraddress scheme for SIP endpoints, to allow selection of the gateway inLondon. In general, the gateway selection should be biased towards thegateway that is closer to the H.323 endpoint. Let's look at ways ofachieving this, without changing the SIP user's addressing scheme.

Just as Pre-Routing for outbound calls must be based on calleeinformation, the Gateway selection for inbound calls must be based oncaller information. In general, for accuracy in the bandwidthaccounting, the gateway selection must be based on the proximity to theH.323 endpoint; and not the SIP endpoint. This is because the SIPendpoints are already managed and their topology represented by the SIPinfrastructure.

Accordingly, two architectural recommendations for bandwidth accountingmay be made. While recommendation #1 will always be used for theoriginating video network selection, recommendation #2 may be used as anadditional precursor. Specifically, the latter addresses gatewayselection and the SIP user address scheme.

Recommendation #1: Video Network Selection

i. The SIP-H.323 gateway will always provide the H.323 endpoint caller'sIP address.

ii. The SIP infrastructure will use its IP Range configuration todetermine the originating video network. In case of insufficient IPRange configuration, the originating Video Network will be the defaultvideo network, designated for calls with H.323 endpoints.

Recommendation #2: Gateway Selection and Redirection

So far, we have identified three possible options:

Option #1: Gateway Prefix based Gateway Selection:

i. The Gateway has a 1:1 relationship with the SIP infrastructure.

ii. We use configurable Gateway Prefix(es) in the SIP endpoint'sadvertised H.323 user address. Calls to SIP users will have the H.323alias begin with the gateway prefix.

iii. Gateway Selection to be based on the gateway prefix dialed by theH.323 endpoint caller.

Option #1+: Gateway Redirection:

In order to ensure the best possible bandwidth accounting, the SIPinfrastructure (or B2BUA) may implement a mechanism, to redirect theinbound call from an H.323 endpoint to another pair of SIPinfrastructure and gateway. This will be accomplished using thefollowing steps:

i. The gateway receives an incoming H.323 call and translates it into aSIP INVITE directed to the SIP server. It provides the IP address of theH.323 endpoint.

ii. The SIP server looks at topological information, specificallyenterprise-wide IP Range configuration, to determine the best videonetwork hosted by any of the SIP servers in the enterprise. From thevideo network, it determines the SIP server and ultimately the gatewaythat is most suitable for the call. If this is not the gateway that sentthe INVITE, then the SIP server refuses the SIP INVITE with a request toredirect the call to another destination. As part of responding to thegateway's INVITE in such a manner, the SIP server specifies the addressinformation of the destination gateway for redirection.

iii. The gateway intercepts the SIP server's redirection 3xx response(usually 302); and in turn, it responds to the H.323 caller with theaddressing information. Please refer to the section on GatewayRedirection for specific H.323 mechanisms for forwarding/redirecting acall. Our implementation for H.323 call redirection prefers the usage ofthe H.225.0 Facility message.

To make this easy to manage and effective, we provide the followingunique features:

-   -   Configuration support to enable or disable Gateway Redirection        (enabled by default)    -   Propagation of network configuration and gateway addresses        between SIP servers    -   SIP and H.323 redirection support in the SIP server    -   Redirection support in the SIP-H.323 gateway

Option #2: H.323 neighbor Gatekeeper based Gateway Selection:

i. The gateway has a 1:1 relationship with the SIP server.

ii. In an embodiment, a configurable global/deployment-level prefix inthe SIP endpoint's advertised H.323 user address may be used. Calls toSIP users will have the H.323 alias begin with the global prefix.

iii. In an embodiment, the H.323 neighbor Gatekeeper may be implementedas part of a SIP-H.323 gateway solution. The neighbor Gatekeeperregisters with the enterprise's external H.323 Gatekeeper for addressresolution upon calls to SIP endpoints.

iv. In an embodiment, only one H.323 neighbor Gatekeeper may be allowedper deployment. It bears a 1: n relationship with SIP-H.323 gateways;and it would be aware of the respective SIP servers' IP Rangeconfigurations. The neighbor Gatekeeper then provides the neededresolution for Gateway Selection, based on Gateway's proximity to thecaller (which, in this case is the H.323 endpoint).

Option #3: Single Gateway per deployment:

i. This option would enforce one SIP-H.323 gateway perdeployment/enterprise, and it will have a 1: n relationship with the SIPservers. (Each server may in turn manage multiple video networks).

ii. We use a configurable prefix in the SIP endpoint's advertised H.323user address. Calls to SIP users will have the H.323 alias begin withthis prefix.

iii. The gateway will be aware of the SIP servers' IP Rangeconfigurations.

iv. In an embodiment, the SIP-H.323 gateway will implement a gatewaymanager, which will be used for central configuration purposes.

In an embodiment, the Gateway Selection follows:

-   -   recommendation #1 for network selection; and    -   recommendation #2, options 1 & 1+ for gateway selection &        redirection.

In an embodiment, the system and method allows for the usage ofrecommendation #2, options 2 and 3, as needed for a deployment. Option 2is recommended for larger deployments, while option 3 is only suitablefor small deployments.

9. Gateway Redirection

In order to ensure the best possible bandwidth accounting and resourceallocation, the SIP infrastructure (or B2BUA) and the SIP-H.323 gatewaymay implement a mechanism, to redirect the inbound call from an externalH.323 endpoint to another instance of the SIP-H.323 gateway deployedelsewhere. This is accomplished by using the steps 601-608, illustratedin FIG. 6:

1. The SIP-H.323 gateway receives an incoming H.323 call and translatesit into a SIP INVITE directed to the SIP infrastructure. It provides theIP address of the H.323 endpoint in the “From:” field of the INVITE(step 601).

2. The SIP infrastructure looks at topological information, specificallyenterprise-wide IP Range configuration (602), to determine the bestnetwork or bandwidth pool to host the external endpoint on. From thenetwork, it determines the B2BUA and ultimately the SIP-H.323 gatewayinstance that is most suitable for the call. If this is not theSIP-H.323 gateway instance that sent the INVITE, then the SIPinfrastructure refuses the SIP INVITE with a request to redirect theH.323 call to another H.323 destination. As part of responding to theSIP-H.323 gateway INVITE in such a manner, the SIP infrastructure mayspecify the H.323 destination as the H.323 address of the appropriateSIP-H.323 gateway instance, more suited for the call.

3. In an embodiment, the SIP-H.323 gateway intercepts the SIPinfrastructure's redirection 3xx response (usually 302); and in turn, itresponds to the external H.323 caller with the addressing information ina Facility message.

In an embodiment, the H.323 Call Redirection may be implemented usingthe Facility Message from the H.225.0 specification. While this may be apreferred approach, the invention also provides for the support othermethods as allowed by the endpoints. In an embodiment, the user-to-userinformation element (UUIE) of the facility message is used primarily forcall redirection. The UUIE contains a field, facilityReason, whichindicates the nature of the redirection. In an embodiment, the reasoncould be routeCallToGatekeeper or callForwarded. Various exemplary H.323methods are described below:

H.225.0 Specification: Facility Message (Typically PreferredImplementation)

In order to signal call redirection specific to H.323 procedures (callforwarding, redirecting a call to the MC, or forcing a call to be routedto the gatekeeper) or in case of supplementary service signalingaccording to ITU-T H.450, the User-user information element of theFacility message is used. In order to indicate call forwarding, theFacility IE shall be empty and the Facility-UUIE shall indicate in thealternativeAddress or the alternativeAliasAddress the terminal to whichthe call is to be redirected. In this case, the facilityReason shall beset to callForwarded.

Call Forward

In certain cases, an H.323 endpoint might determine that a call needs tobe forwarded. The endpoint could then send a facility message with afacilityReason of callForwarded. This message includes the address ofthe new destination (either an alternativeAddress oralternativeAliasAddress). In an embodiment, upon receiving the facilitymessage, the peer source endpoint sends a release complete message tothe original destination endpoint and initiates a new call using the newdestination address supplied in the facility message. The releasecomplete message could contain a ReleaseCompleteReason offacilityCallDeflection.

Supplementary H.450.3 Call Deflection

Call deflection is a feature under H.450.3 Call Diversion (CallForwarding) that allows a called H.323 endpoint to redirect theunanswered call to another H.323 endpoint.

10. Third-Party Call Control

The third-party call control allows for the following:

-   -   Putting an endpoint on hold, or resuming it. This is done by        employing re-INVITEs on the SIP side and translating them to        logical channel manipulation on the H.323 side.    -   Transfer from one endpoint to another, or to a recording agent,        for applications such as voice mail, by using REFER on the SIP        side, or using 3pcc, by putting the SIP side on hold, and        swapping the SIP UA.    -   Multiparty call setup and collapse, by transferring a H.323        endpoint to a SIP Focus conferencing server.

(It is noted that a description of third-party call control procedureshas been provided earlier.)

The exemplary sequence diagram shown in FIG. 7 illustrates the procedure700 for transferring an H.323 endpoint (X) from one SIP endpoint (A) 701to another (B) 702.

11. Handling Provisional Responses

As part of handling an inbound call, the SIP-H.323 gateway may directits SIP UA in sending an outgoing INVITE request to the configured SIPB2BUA. When the gateway receives a provisional (1xx) response to itsINVITE, it starts or resets its transaction timer, viz. thecompletionTimer. When this timer goes off the SIP transaction isterminated. The interval used to control the completionTimer depends onthe type of the transaction, and it could be one of the following twovalues:

-   -   InviteTimeout: is used for INVITE transactions. The default is        32 seconds.    -   NonInviteTimeout: for all other methods. The default value is 16        seconds.

These values are only used by the completionTimer, and changing themdoes not influence anything else. These time intervals can be configuredand queried, by using the following XML-RPC:

sgwApiV1.setSipInviteTimeout <time-interval-in-milliseconds>sgwApiV1.querySipInviteTimeout sgwApiV1.setSipNonInviteTimeout<time-interval-in-milliseconds> sgwApiV1.querySipNonInviteTimeout

The gateway supports “transparent” inbound call transfer, where a SIPproxy forwards the INVITE to a voicemail server on its own and sends aprovisional 181 response to the gateway, as per the section 6.1 of RFC4458. The handling of provisional responses is described above.

12. Inbound Call Redirection

In an embodiment, the SIP-H.323 gateway supports redirection, triggeredby a 3xx response to an outgoing INVITE for an inbound call.Specifically, it supports two types of redirection: the end-to-end H323redirection and the SIP-side redirection. The type of call redirectionis determined by the parameters to the SIP URI that is used to specifythe alternate address, in the “Contact:” header field of the response.

A. SIP-Side Redirection

In an embodiment, the SIP-H.323 gateway supports SIP redirection, as perthe section 6.2 of RFC 4458. The message flow diagram 800 illustrated inFIG. 8 shows an example of a SIP-side call redirection, where the H.323leg of the call is left intact, while the SIP-peer is switched. Here, anH.323 endpoint—Alice 804 calls a SIP endpoint—Bob 802. Bob 802 is busy,but he decides to forward the session to another SIP endpoint—Dave 801,by sending a 302 response to the gateway with Dave's address.

In an embodiment, the SIP-H.323 gateway keeps the H.323 side of the callintact, while re-issuing the initial outgoing INVITE on the SIP side tothe new destination (Dave). Unlike the end-to-end H.323 redirection, thegateway remains involved in the call, subsequent to redirection.

B. End-to-End H323 Redirection

The message flow shown in the diagram presented in FIG. 9 illustrates anexemplary end-to-end H.323 call redirection 900. The call was originallyplaced from an H323 endpoint—Alice 903, through the SIP-H.323 gateway104, to a SIP endpoint—Bob 901. This call was redirected by Bob 901, whopasses an alternate H.323 address to the gateway in the 302 response.The gateway intercepts this, and it sends a Facility message to Alice903, with this alternate H.323 address. This results in the automaticplacement of a call from Alice to Carol 904, who is at the alternateH323 address.

In this case, the Contact header of the 302 response message will havethe addressing information required to redirect the incoming H.323 callto another H.323 endpoint, MCU, or Gateway. The H.323 addressinginformation is encoded by appending the following parameters to the SIPURI, in the “Contact:” header field:

-   -   alternate-host: IP address of H.323 endpoint,    -   alternate-port: port number of the H.323 endpoint,    -   alternate-alias: the alias of the H.323 endpoint, to which the        call is being redirected.

As shown in the above call flow, neither Bob, nor the gateway isinvolved in the call, subsequent to redirection.

The SIP URI in the “Contact:” header field must follow this syntax:sip:<sgw-sip-user>@<sgw-hostport>;<h323-address-info> where the<h323-address-info> could be one of the following:

~ alternate-alias={alias}, or ~alternate-host={host}[;alternate-port={port}], or ~alternate-alias={alias};alternate-host={host}[;alternate-port={port}]

If neither keyword, viz. neither alternate-alias nor alternate-host arepresent in the SIP URI, then the gateway will attempt to invoke theSIP-side call redirection, which is described in the next section.

An example of the 302 response message is shown below.

SIP/2.0 302 Recipient has moved temporarily, new URL available CSeq: 1INVITE Via: SIP/2.0/UDP 172.16.11.12:6060;\branch=c76d00b2-ecf9-1810-83af 00123f72970e User-Agent: avnm/10.0.2.27From: “Alice” <h323:6542@172.16.11.213:3232;transport=udp>;\tag=c76d00b2-ecf9-1810-83ae-00123f72970e Call-ID:892400b2-ecf9-1810-83ae-00123f72970e@host To:<sip:333@172.16.11.74:5063;user=dialedDigits>;tag=030214da4461 Contact:<sip:SGW_UA@172.16.11.12:6060;\alternate-host=172.16.12.202;alternate-alias=123> Allow: INVITE, CANCEL,BYE, ACK, INFO

Dial Patterns Used in Inbound (H.323 to SIP) Calls

An embodiment of the inventive concept provides native support for SIP,H.323 and proprietary signaling protocols, in a network and callmanagement infrastructure. An embodiment of the invention is implementedusing inventive SIP-H.323 Signaling-only Gateway and a third party callcontrol server.

Inbound Dial Patterns

In an embodiment, the inventive server provides a configuration(sgw.ini) parameter, viz. SIP_InboundDialPattern, to specify how thedestination/callee SIP address will be conveyed in the “To:” field of anoutgoing SIP INVITE for a H.323 to SIP inbound call. This is also usedfor conveying the H.323 endpoint's addressing information in the “From:”field of the outgoing INVITE.

Registration Prefix and Extension

In an embodiment, the inventive server registers with a Gatekeeper, as aGateway, and it uses its registration prefix while doing so. For inboundcalls in gatekeeper-managed environments, the inventive server onlypasses the extension to the SIP side. The extension is simply thedialedDigits alias, without the gateway's registration prefix.Stripping-off the registration prefix is not applicable to unmanagedenvironments.

SIP B2BUA

In an embodiment, the inventive server will transmit the outgoing SIPINVITE for the inbound call to the address configured in theSIP_B2bUaUrl from sgw.ini parameter, or to the B2BUA configured by usingthe XML-RPC API. While this parameter typically points to a SIP B2BUA,or to a SIP 3pcc infrastructure component in production, one could alsospecify the address of a SIP endpoint for purposes of testing withstandalone endpoints.

Supported SIP Inbound Dial Patterns

1. SIP URI

To: sip:{to-user-part}@{b2bua-address}; user=dialed Digits

From: sip: {from-user-part} @{sgw-address}

Required Name Description field to-user-part extension, which thedialedDigits alias, Yes after stripping off the gateway prefix, or afixed string when an extension is not available, viz. “receptionist”b2bua-address The address of the SIP B2BUA, as Yes configured using theXML-RPC API, or in the SIP_B2bUaUrI configuration parameter.user=dialedDigits This parameter will be appended to the No URI in the“To:” field, if the configuration parameter SIP_DialedDigitEnable is setto True. from-user-part h323-alias, or Yes h323host={h323host}, orh323-alias;h323host={h323host} sgw-address Host-port of Inventiveserver. Yes

To enable this dial pattern, the following configuration (sgw.ini)parameter should be set:

SIP_InboundDialPattern=1

Or, one can also use the XML-RPC API sgwApiV1.SetInboundDialPattern toset the inbound dial pattern.

2. H.323 URI

To: h323:[extension]@{b2bua-address}

From: h323: {h323-address}

Required Name Description field extension The dialedDigits alias, afterstripping No off the gateway prefix. b2bua-address The address of theSIP B2BUA, as Yes configured using the XML-RPC API, or in theSIP_B2bUaUrI configuration parameter. h323-address The H.323 callerendpoint's host, or Yes the H.323 caller's dialedDigits alias, or Both.

To enable this dial pattern, the following configuration (sgw.ini)parameter should be set:

SIP_InboundDialPattern=2

Or, one can also use the XML-RPC API sgwApiV1.SetInboundDialPattern toset the inbound dial pattern.

This is also the default value.

3. TEL URI

To: tel:{tel-uri-prefix}[extension]

From: tel:{tel-uri-prefix} [e164-alias]

Required Name Description field tel-uri- We introduce a new parameter,called Yes prefix SIP_TelUriPrefix, which will be used to prefix the“tel:” URI. The default value would be “+1-”. This will be useful forcases where we need to relay the address as a “tel:” URI, in unmanagedenvironments, where we don't have an extension for the endpoint.extension The dialedDigits alias, without the gateway No prefix.e164-alias The H.323 caller's dialedDigits alias. No

Some rules with regards to the “tel:” URI prefix:

1. In addition to digits, we allow ‘+’ and ‘−’ characters, in the “tel:”URI prefix.

The ‘+’ is only allowed as the first character in the prefix.

The ‘−’ must follow a digit.

The “tel:” URI prefix must contain at least one digit.

2. We do not automatically insert any ‘+’ and ‘−’ characters, unlessthey are explicitly present in the “tel:” URI prefix.

3. When we receive an absolute E.164 address that begins with a ‘+’,then we pass it as is. In such cases, we do not strip the registrationprefix, and we do not pre-pend the “tel:” URI prefix. In all othercases:

we first strip the registration prefix (if it is present in thedialedDigits), and

we then pre-pend the “tel:” URI prefix.

To enable this dial pattern, the following configuration (sgw.ini)parameter must be set:

SIP_InboundDialPattern=3

Or, one can also use the XML-RPC API sgwApiV1.setInboundDialPattern toset the inbound dial pattern. Finally, one can also use the XML-RPCAPI-sgwApiV1.setTelUriPrefix to set the “tel:” URI prefix.

Examples illustrating the usage of Dial Patterns in inbound calls

The following table shows an exemplary mapping between the “To:” fieldin the SIP INVITE, and the H.323 address or string, as dialed at theH.323 endpoint.

In these examples, the H.323 caller's IP address is 74.125.45.1 andalias is “456”.

The SIP-H.323 gateway IP address is 74.125.45.2, SIP port is 6060, andits “tel:” URI prefix is “+1−”.

Finally, the IP address of the SIP B2BUA is 74.125.45.3; and the SIPcallee's extension is “23”.

The Inventive server is registered with a Gatekeeper, and itsregistration prefix is “1”, in all of the examples.

Pattern Dial string at e/p “To:” field in the SIP INVITE “From:” fieldin the SIP INVITE 1 74.125.45.2##123 sip:23@74.125.45.3sip:456;h323host=74.125.45.1 @74.125.45.2:6060 74.125.45.2sip:receptionist@74.125.45.3 sip:456;h323host=74.125.45.1@74.125.45.2:6060 123 sip:23@74.125.45.3 sip:456@74.125.45.2:6060 274.125.45.2##123 h323:23@74.125.45.3 h323:456@74.125.45.1 74.125.45.2h323:@74.125.45.3 h323:456@74.125.45.1 123 h323:23 h323:456 374.125.45.2##123 tel:+1-23 tel:+1-456 74.125.45.2 tel:+1 tel:+1-456 123tel:+1-23 tel:+1-456

Note:

The addition of the prefix by the caller, and the stripping-off of theprefix by the SGW; only applies to GK-managed environments. A stringdialed as “74.125.45.2##1” will result in the dialedDigits alias of “1”passed in the “To:” field of the outgoing SIP INVITE for the inboundcall, in an unmanaged environment.

Dial Patterns Used in Outbound (SIP to H.323) Calls

Outbound Dial Patterns

In an embodiment, the inventive server supports a variety of patternsthat can be used by its peer SIP UA/B2BUA, to convey the destinationH.323 address, in the “To” header or “Request-URI” of a SIP INVITE sentto the SIP-H.323 gateway server, for a SIP to H.323 outbound call.

Based on the syntax and rules of the outbound dial patterns, theSIP-H.323 gateway server will parse the “To” header or “Request-URI” ofthe incoming SIP INVITE, in order to gather the H.323 callee'sinformation.

In an embodiment, the inventive server supports all patterns. Users arefree to use (or not use) any specific patterns in a particulardeployment, without needing specific configuration for this. The targetfor parsing out the H.323 destination information is configurablethough, as described at the end of this document, just before thesection on examples.

Supported SIP Outbound Dial Patterns

1. Encoding the destination H.323 address in the user-part of the SIPURI

sip:{h323user}[;h323host={h323host}[;h323port={h323port}]]@{sgw-hostport}

Required Name Description field h323user H.323 user. Yes. 1*(%x21-24 /%x26-3F / %x41-7F / escaped) (Please refer to RFC 3508 for formal syntaxdefinition.) h323host H.323 host. No. hostname / IPv4address (Pleaserefer to RFC 3508 for formal syntax definition.) h323port H.323 port.No. 1*DIGIT If not specified, a default value of 1720 is assumed.(Please refer to RFC 3508 for formal syntax definition.) sgw- SIP-H.323gateway server host and port. Yes. hostport host[“:”port] (Please referto RFC 3261 for formal syntax definition.)

In an embodiment, this dial pattern is employed when the SIP-H.323gateway receives an incoming INVITE where the “To” header or“Request-URI” contains the callee information provided as a SIP URI:sip:{user}@{sgw-hostport}, where the user part may be expanded as{h323user}[;h323host={h323host}[;h323port={h323port}]].

In an embodiment, the SIP-H.323 gateway may use the user, host and portinformation to form a H.323 callee URI, as per RFC 3508. The h323hostmust be specified in environments that are not managed by a H.323gatekeeper. Note that this syntax is optimized to produce the simplestdial-string in typical GK-managed environments, viz.h323user@sgw-hostport. In an unmanaged environment, if one only has theH.323 host part, but the H.323 endpoint does not have an alias to use inthe H.323 user-part, then one could include anything in the H.323user-part, and the dial string could, for example, be as follows:

“0;h323host=192.168.112.188@mysgw”.

2. Providing the destination H.323 address as a H.323 URI

h323:{address}

Required Name Description field address H.323 address. Yes. user /“@”hostport / user“@”hostport (Please refer to RFC 3508 for formalsyntax definition.)

In an embodiment, the dial pattern is employed when the SIP-H.323gateway receives an incoming INVITE where the “To” header or“Request-URI” contains the callee information provided as a H.323 URI.The SIP-H.323 gateway server will simply validate the URI and place anH.323 call. This pattern is highly recommended when the INVITEs areintercepted by a B2BUA, or a 3pcc server, before making it to the SGW.

3. Providing the Destination H.323 Address as a H.323 URI

tel:{global-number-digits}

Required Name Description field global-number- H.323 address. Yes.digits “+” *phonedigit DIGIT *phonedigit (Please refer to RFC 3966 forformal syntax definition.)

In an embodiment, the dial pattern is employed when the SIP-H.323gateway receives an incoming INVITE where the “To” header or“Request-URI” contains the callee information provided as a “tel:” URI.We currently support global-number types only, without supportingparameters to the URI. (The term “global-number-digits” should beinterpreted per RFC 3966). The SIP-H.323 gateway server will simplyvalidate the URI and place an H.323 call. This pattern is only usefulfor gatekeeper-managed environments. The value of theglobal-number-digits will be treated as an E.164 number for the outboundH.323 call.

Configuring the Outbound Dial Patterns Target

In an embodiment, the target for parsing out the H.323 destinationinformation is configurable. This influences whether the SIP-H.323gateway server will parse H.323 callee information from the “To” headeror from the “Request-URI”. Note that the SIP header parsing rules willapply to the entire SIP dialog, and not just to the SIP transaction thatstarted the dialog. The sgw.ini parameter:SIP_OutboundDialPatternUsesRequestURI is added to influence thisbehavior, and it is also configurable by using the XML-RPC API. Thedefault value for this parameter is ‘False’, which means that theSIP-H.323 gateway server will parse the “To” header to get the H.323callee information. When set value to ‘True’, the SIP-H.323 gatewayserver parse the “Request-URI” to get the H.323 callee's information. Inthe latter case, the user agent matching logic that is normally invokedas part of INVITE-processing will be bypassed by the SIP-H.323 gateway.This logic will be replaced to allow more flexibility in therequest-URI.

The following new XML-RPC APIs are added to support this configuration:

sgwApiV1.SetOutboundDialPatternUsesRequestURI (...)sgwApiV1.QueryOutboundDialPatternUsesRequestURI (...)

Examples Illustrating the Usage of Dial Patterns in Outbound Calls

In our examples, the SGW's IP address is 74.125.45.2, while the H.323callee's IP address is 74.125.45.1, and their extension is “123”. Thefollowing illustrates the construction of the H.323 address by the SGW.

Pattern request-URI or “To:” field in the incoming SIP INVITE H.323 URIconstructed 1 sip:123;h323host=74.125.45.1;h323port=1725@74.125.45.2h323:123@74.125.45.1:1725 sip:123;h323host=74.125.45.1@74.125.45.2h323:123@74.125.45.1 sip:123@74.125.45.2 h323:123 2 h323:123@74.125.45.1h323:123@74.125.45.1 h323:123 h323:123 3 tel:123 h323:123

Exemplary Computer Platform

FIG. 10 illustrates an exemplary embodiment of a computer platform uponwhich the inventive system may be implemented. Specifically, FIG. 10 isa block diagram that illustrates an embodiment of a computer/serversystem 1000 upon which an embodiment of the inventive methodology may beimplemented. The system 1000 includes a computer/server platform 1001,peripheral devices 1002 and network resources 1003.

The computer platform 1001 may include a data bus 1005 or othercommunication mechanism for communicating information across and amongvarious parts of the computer platform 1001, and a processor 1005coupled with bus 1001 for processing information and performing othercomputational and control tasks. Computer platform 1001 also includes avolatile storage 1006, such as a random access memory (RAM) or otherdynamic storage device, coupled to bus 1005 for storing variousinformation as well as instructions to be executed by processor 1005.The volatile storage 1006 also may be used for storing temporaryvariables or other intermediate information during execution ofinstructions by processor 1005. Computer platform 1001 may furtherinclude a read only memory (ROM or EPROM) 1007 or other static storagedevice coupled to bus 1005 for storing static information andinstructions for processor 1005, such as basic input-output system(BIOS), as well as various system configuration parameters. A persistentstorage device 1008, such as a magnetic disk, optical disk, orsolid-state flash memory device is provided and coupled to bus 1001 forstoring information and instructions.

Computer platform 1001 may be coupled via bus 1005 to a display 1009,such as a cathode ray tube (CRT), plasma display, or a liquid crystaldisplay (LCD), for displaying information to a system administrator oruser of the computer platform 1001. An input device 1010, includingalphanumeric and other keys, is coupled to bus 1001 for communicatinginformation and command selections to processor 1005. Another type ofuser input device is cursor control device 1011, such as a mouse, atrackball, or cursor direction keys for communicating directioninformation and command selections to processor 1005 and for controllingcursor movement on display 1009. This input device typically has twodegrees of freedom in two axes, a first axis (e.g., x) and a second axis(e.g., y), that allows the device to specify positions in a plane.

An external storage device 1012 may be coupled to the computer platform1001 via bus 1005 to provide an extra or removable storage capacity forthe computer platform 1001. In an embodiment of the computer system1000, the external removable storage device 1012 may be used tofacilitate exchange of data with other computer systems.

The invention is related to the use of computer system 1000 forimplementing the techniques described herein. In an embodiment, theinventive system may reside on a machine such as computer platform 1001.According to one embodiment of the invention, the techniques describedherein are performed by computer system 1000 in response to processor1005 executing one or more sequences of one or more instructionscontained in the volatile memory 1006. Such instructions may be readinto volatile memory 1006 from another computer-readable medium, such aspersistent storage device 1008. Execution of the sequences ofinstructions contained in the volatile memory 1006 causes processor 1005to perform the process steps described herein. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the invention. Thus,embodiments of the invention are not limited to any specific combinationof hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 1005 forexecution. The computer-readable medium is just one example of amachine-readable medium, which may carry instructions for implementingany of the methods and/or techniques described herein. Such a medium maytake many forms, including but not limited to, non-volatile media andvolatile media. Non-volatile media includes, for example, optical ormagnetic disks, such as storage device 1008. Volatile media includesdynamic memory, such as volatile storage 1006.

Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, any other optical medium, punchcards, papertape, anyother physical medium with patterns of holes, a RAM, a PROM, an EPROM, aFLASH-EPROM, a flash drive, a memory card, any other memory chip orcartridge, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to processor 1005 forexecution. For example, the instructions may initially be carried on amagnetic disk from a remote computer. Alternatively, a remote computercan load the instructions into its dynamic memory and send theinstructions over a telephone line using a modem. A modem local tocomputer system can receive the data on the telephone line and use aninfra-red transmitter to convert the data to an infra-red signal. Aninfra-red detector can receive the data carried in the infra-red signaland appropriate circuitry can place the data on the data bus 1005. Thebus 1005 carries the data to the volatile storage 1006, from whichprocessor 1005 retrieves and executes the instructions. The instructionsreceived by the volatile memory 1006 may optionally be stored onpersistent storage device 1008 either before or after execution byprocessor 1005. The instructions may also be downloaded into thecomputer platform 1001 via Internet using a variety of network datacommunication protocols well known in the art.

The computer platform 1001 also includes a communication interface, suchas network interface card 1013 coupled to the data bus 1005.Communication interface 1013 provides a two-way data communicationcoupling to a network link 1015 that is coupled to a local network 1015.For example, communication interface 1013 may be an integrated servicesdigital network (ISDN) card or a modem to provide a data communicationconnection to a corresponding type of telephone line. As anotherexample, communication interface 1013 may be a local area networkinterface card (LAN NIC) to provide a data communication connection to acompatible LAN. Wireless links, such as well-known 802.11a, 802.11b,802.11g and Bluetooth may also used for network implementation. In anysuch implementation, communication interface 1013 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 1013 typically provides data communication through one ormore networks to other network resources. For example, network link 1015may provide a connection through local network 1015 to a host computer1016, or a network storage/server 1017. Additionally or alternatively,the network link 1013 may connect through gateway/firewall 1017 to thewide-area or global network 1018, such as an Internet. Thus, thecomputer platform 1001 can access network resources located anywhere onthe Internet 1018, such as a remote network storage/server 1019. On theother hand, the computer platform 1001 may also be accessed by clientslocated anywhere on the local area network 1015 and/or the Internet1018. The network clients 1020 and 1021 may themselves be implementedbased on the computer platform similar to the platform 1001.

Local network 1015 and the Internet 1018 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link1015 and through communication interface 1013, which carry the digitaldata to and from computer platform 1001, are exemplary forms of carrierwaves transporting the information.

Computer platform 1001 can send messages and receive data, includingprogram code, through the variety of network(s) including Internet 1018and LAN 1015, network link 1015 and communication interface 1013. In theInternet example, when the system 1001 acts as a network server, itmight transmit a requested code or data for an application programrunning on client(s) 1020 and/or 1021 through Internet 1018,gateway/firewall 1017, local area network 1015 and communicationinterface 1013. Similarly, it may receive code from other networkresources.

The received code may be executed by processor 1005 as it is received,and/or stored in persistent or volatile storage devices 1008 and 1006,respectively, or other non-volatile storage for later execution.

It should be noted that the present invention is not limited to anyspecific firewall system. The inventive policy-based content processingsystem may be used in any of the three firewall operating modes andspecifically NAT, routed and transparent.

Finally, it should be understood that processes and techniques describedherein are not inherently related to any particular apparatus and may beimplemented by any suitable combination of components. Further, varioustypes of general purpose devices may be used in accordance with theteachings described herein. It may also prove advantageous to constructspecialized apparatus to perform the method steps described herein. Thepresent invention has been described in relation to particular examples,which are intended in all respects to be illustrative rather thanrestrictive. Those skilled in the art will appreciate that manydifferent combinations of hardware, software, and firmware will besuitable for practicing the present invention. For example, thedescribed software may be implemented in a wide variety of programmingor scripting languages, such as Assembler, C/C++, perl, shell, PHP,Java, etc.

Moreover, other implementations of the invention will be apparent tothose skilled in the art from consideration of the specification andpractice of the invention disclosed herein. Various aspects and/orcomponents of the described embodiments may be used singly or in anycombination in a teleconferencing system achieving interoperabilitybetween teleconferencing endpoints that follow different communicationprotocols. It is intended that the specification and examples beconsidered as exemplary only, with a true scope and spirit of theinvention being indicated by the following claims.

1. A teleconferencing system for achieving interoperability between atleast two of a first endpoint following SIP protocol, a second endpointfollowing H.323 protocol and a third endpoint following a proprietaryprotocol, the teleconferencing system comprising a signaling-onlygateway and a call control server, wherein the signaling-only gatewayand a call control server are operable to perform policy-basedmanagement of calls between the at least two of the first endpoint, thesecond endpoint and the third endpoint, enabling a direct flow of mediadata between respective endpoints.
 2. The teleconferencing system ofclaim 1, wherein the signaling-only gateway and the call control serverare additionally operable to perform at least one policy-basedmanagement function.
 3. The teleconferencing system of claim 2, whereinthe policy-based management comprises routing calls involvingcombinations of the at least two of the first endpoint, the secondendpoint and the third endpoint based on proximity across at least oneIP network using a pre-configured IP range to ensure selection of anoptimal gateway from a set of infrastructure components and redirectionof at least one of the first endpoint, the second endpoint and the thirdendpoint to alternate gateways, if dictated by a routing policy.
 4. Theteleconferencing system of claim 2, wherein the policy-based managementcomprises managing bandwidth and performing usage accounting for callsinvolving combinations of the at least two of the first endpoint, thesecond endpoint and the third endpoint.
 5. The teleconferencing systemof claim 2, wherein the policy-based management comprises seamlesslysetting up and managing calls between the at least two of the firstendpoint, the second endpoint and the third endpoint.
 6. Theteleconferencing system of claim 5, wherein seamlessly setting up callscomprises transfer, multiparty conferencing, and seamless conversion ofcalls involving the at least two of the first endpoint, the secondendpoint and the third endpoint.
 7. The teleconferencing system of claim5, wherein seamlessly setting up calls comprises determining capabilityof at least one of the first endpoint, the second endpoint and the thirdendpoint and applying corresponding call control procedures needed toachieve a predetermined call setup operation.
 8. A method for achievinginteroperability between at least two of a first endpoint following SIPprotocol, a second endpoint following H.323 protocol and a thirdendpoint following a proprietary protocol, the method being performed bya teleconferencing system comprising a signaling-only gateway and a callcontrol server, the method comprising performing policy-based managementof calls between the at least two of the first endpoint, the secondendpoint and the third endpoint using the signaling-only gateway and thecall control server to enable a direct flow of media data betweenrespective endpoints.
 9. The method of claim 8, wherein thesignaling-only gateway and the call control server are operable toprovide at least one policy-based management function.
 10. The method ofclaim 9, wherein the policy-based management comprises routing callsinvolving combinations of the at least two of the first endpoint, thesecond endpoint and the third endpoint based on proximity across atleast one IP network using a pre-configured IP range to ensure selectionof an optimal gateway from a set of infrastructure components andredirection of at least one of the first endpoint, the second endpointand the third endpoint to alternate gateways, if dictated by a routingpolicy.
 11. The method of claim 9, wherein the policy-based managementcomprises managing bandwidth and performing usage accounting for callsinvolving combinations of the at least two of the first endpoint, thesecond endpoint and the third endpoint.
 12. The method of claim 9,wherein the policy-based management comprises seamlessly setting up andmanaging calls between the at least two of the first endpoint, thesecond endpoint and the third endpoint.
 13. The method of claim 12,wherein seamlessly setting up calls comprises transfer, multipartyconferencing, and seamless conversion of calls involving the at leasttwo of the first endpoint, the second endpoint and the third endpoint.14. The method of claim 12, wherein seamlessly setting up callscomprises determining capability of at least one of the first endpoint,the second endpoint and the third endpoint and applying correspondingcall control procedures needed to achieve a predetermined call setupoperation.
 15. A computer-readable medium embodying computer-executableinstructions, which, when executed by one or more processors of ateleconferencing system comprising a signaling-only gateway and a callcontrol server, are operable to cause the one or more processors toperform a method for achieving interoperability between at least two ofa first endpoint following SIP protocol, a second endpoint followingH.323 protocol and a third endpoint following a proprietary protocol,the method comprising performing policy-based management of callsbetween the at least two of the first endpoint, the second endpoint andthe third endpoint using the signaling-only gateway and the call controlserver to enable a direct flow of media data between respectiveendpoints.
 16. The computer-readable medium of claim 15, wherein thepolicy-based management comprises routing calls involving combinationsof the at least two of the first endpoint, the second endpoint and thethird endpoint based on proximity across at least one IP network using apre-configured IP range to ensure selection of an optimal gateway from aset of infrastructure components and redirection of at least one of thefirst endpoint, the second endpoint and the third endpoint to alternategateways, if dictated by a routing policy.
 17. The computer-readablemedium of claim 15, wherein the policy-based management comprisesmanaging bandwidth and performing usage accounting for calls involvingcombinations of the at least two of the first endpoint, the secondendpoint and the third endpoint.
 18. The computer-readable medium ofclaim 15, wherein the policy-based management comprises seamlesslysetting up and managing calls between the at least two of the firstendpoint, the second endpoint and the third endpoint.
 19. Thecomputer-readable medium of claim 18, wherein seamlessly setting upcalls comprises transfer, multiparty conferencing, and seamlessconversion of calls involving the at least two of the first endpoint,the second endpoint and the third endpoint.
 20. The computer-readablemedium of claim 18, wherein seamlessly setting up calls comprisesdetermining capability of at least one of the first endpoint, the secondendpoint and the third endpoint and applying corresponding call controlprocedures needed to achieve a predetermined call setup operation.